今天,我們將把 Observability 官方教學文件來好好地萃取精華。
本篇的主題包含有:
那我們就開始吧!
Observability 並不是什麼黑科技、黑魔法,而是我們所建立系統的一些特性,舉凡穩定度、使用度等等。
而建立一個可觀測的系統,目標在於保證運行的時候,操作者可以偵測到不想要的行為,如系統爆炸、錯誤又或是緩慢的回應,並可以有足夠的資訊來找出問題的根源加以解決。
Elastic Stack 是一個廣受歡迎的控管日誌工具,因為其中的搜索引擎 Elasticsearch,可以簡單有效地搜索日誌的內容。
然而,Elastic Stack 不僅能提供有效率的全文檢索,同時也提供強大的商業分析工具(基於 Lucene values 的資料儲存結構、優化數值資料的儲存方式),除了日誌和指標外,還包含應用程式效能監控,讓維護人員更容易監控系統的狀態,最後,還提供了機器學習用以偵測異常狀態資料的功能。
我們可將 Observability 視為搜索的使用案例,Elastic Stack為所有運營數據帶來快速、可靠和相關的搜索結果,無論數據類型如何,我們都可以查找問題並獲得答案。簡兒言之,Elastic Stack可統一這些工具與一個共同的數據存儲區,監控所有內容,搭配機器學習以發現問題。
下圖展示一個營運上限的系統架構(可以在世界上找到很多公司是使用這樣的方式),並能看出 Elastic Stack 是如何 “觀察” 這個系統的。
NGINX 扮演著 Node.js 應用的一個 proxy,Node.js 應用同時使用了 PostgreSQL 資料庫和 Elasticsearch。
當資料透過 Beats 開始流入 Elasticsearch 中,儲存於 Elasticsearch 的方式稱作 “索引(index)”,一個索引可以想像成是將資料捆成一堆,而預設的索引名稱如下:
{type}beat-{version}-{yyyy-MM-dd}-XXXXXX
當你開始蒐集資料且資料已經開始存入 Elasticseach 中時,你就會需要 “看” 你的資料,換句話說,視覺化你的資料,這時候就是 Kibana 登場的時候啦!Kibana 是一個資料視覺化的工具,可以說是 Elastic Stack 的 UI,而其中有許多先幫你建好的儀表板,對於剛使用的人就可以輕鬆的拿來使用,快速的監看你的系統資料。
在從多個來源收集可觀察數據的同時,我們可能還希望視覺化以便能夠確定問題的根本原因。但問題是:如何連結來自不同來源的資料?答案是 Elastic Common Schema 或簡稱 ECS。
ECS 是一種規範,它提供了一種一致且可自定義的方式在 Elasticsearch 中構建資料,從而便於分析各種來源的數據。這代表著 ECS 使日誌、指標和軌跡間的連結變得更容易,有助於系統觀察。但是,我們通常有自己的數據,並不會直接從 Beat 傳入 Elasticsearch,這時候建議可以將自己的資料依循 ECS。這樣做,不僅使自己的資料可與其他資料相關聯,而且可以通過 ECS 定義直接為你的資料提供更多資訊。
活動可能從應用程式伺服器、IOT 裝置、網站等地方而來,日誌由時間戳記和載明活動發生內容的資料所組成
關於日誌有一些常見且重要的問題點:
ISO-8601
的規範,讓時間的格式可以有統一的標準
日誌的生命週期一般來說可分成六個階段:產生、傳送、處理與儲存、搜索與分析、封存與清除,如下圖示:
Beats 其實是一系列工具的總稱,可以解決下列的問題:
下圖是各種不同的 Beats(好像什麼戰隊或是神奇寶貝道館一樣XDDD):
Filebeat 是其中一種非常好用的日誌處理工具,只要會產生日誌的地方都可以使用它,它可以幫助你將日誌傳送到 Elasticsearch 或其他的系統。
它可以監測某個位置下產生出來的日誌檔案,還可以使用 Modules 來啟動對應常見的系統如 Nginx、MongoDB、Redis...等等。
果真,不整理不知道,一整理下一跳!才整理一半就有點長了,剩下的一半還是留待明天好了,不然像第二天寫的又臭又長,寫的人痛苦,看的人應該更痛苦~(再度重申不是偷懶歐>.*)
今天我們詳細地了解 Observability、Elastic Stack 以及 Logs 的概念,明天再來談談 Metrics 和 APM 吧!